# 前言

在前一章，我们学会如何在 Kubernetes 内部署自己的第一个应用。但是在实际应用中，我们还会遇到一些特定场景：

A 用户是VIP，我怎么才能让VIP用户看到内测版本呢？ 我不想停机，怎么发布新版本呢？ 如何让新版本服务只开放小流量访问呢？ …

显然，这些场景对于我们单纯的访问来看是无法做到的。那么有什么好办法呢？

# 什么是灰度发布

首先我们来看灰度发布。灰度发布是一种发布方式，也叫 金丝雀发布 。**起源是矿工在下井之前会先放一只金丝雀到井里，如果金丝雀不叫了，就代表瓦斯浓度高。原因是金丝雀对瓦斯气体很敏感。**这就是金丝雀发布的又来，非常形象地描述了我们的发布行为。

灰度发布的做法是：会在现存旧应用的基础上，启动一个新版应用。但是新版应用并不会直接让用户访问。而是先让测试同学去进行测试。如果没有问题，则可以将真正的用户流量慢慢导入到新版上。在这中间，持续对新版本运行状态做观察，直到慢慢切换过去，这就是所谓的A/B测试。 当然，你也可以招募一些 灰度用户， 给他们设置独有的灰度标示（Cookie，Header），来让他们可以访问到新版应用。

当然，如果中间切换出现问题，也应该将流量迅速地切换到老应用上。

# 实现方案

在上一章节，我们使用 k8s 部署了 ingress 。这里我们就利用 ingress annotations 中的 canary 配置项来实现灰度发布逻辑。

# 1. 准备新版本的 Service

在开始准备灰度之前，需要准备一套新环境以备流量切分。切换到 deployment 目录，我们新启动一套 v2 的环境配置，在这里可以将原先 v1 的配置文件，拷贝一份替换为 v2 的镜像：

cd deployment && cp v1.yaml v2.yaml

修改 v2.yaml，将 Deployment Name， Service Name 和匹配规则都替换为 v2 ，并将镜像版本替换为 v2

apiVersion: apps/v1
kind: Deployment
metadata:
  name: front-v2
spec:
  selector:
    matchLabels:
      app: nginx-v2
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx-v2
    spec:
      containers:
      - name: nginx
        image: registry.cn-hangzhou.aliyuncs.com/janlay/k8s_test:v2
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: front-service-v2
spec:
  selector:
    app: nginx-v2
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: NodePort

接着使用 kubectl apply 命令使其配置生效：

kubectl apply -f ./v2.yaml

# 2. 根据不同方案进行切分

根据 Cookie 切分流量

基于 Cookie 切分流量。这种实现原理主要根据用户请求中的 Cookie 是否存在灰度标示 Cookie去判断是否为灰度用户，再决定是否返回灰度版本服务。

我们新建一个全新的 ingress 配置文件，名称叫 gary ：

cd ./ingress && vim ./gray.yaml

@前端进阶之旅: 代码已经复制到剪贴板